Книга Настольная книга тимлида разработки ПО - Виктор Большаков

чем они не согласны. Вероятно, вы не вовлекли сотрудников в этап проектирования процесса, что породило их несогласие.

— если доводы разумные, можно включить их в следующую итерацию изменения процесса. Например, исправить его через некоторое время — сообщите об этом сотрудникам и попросите работать пока в текущей версии процесса.

— если их доводы не разумные, объясните почему.

— если это личная неприязнь к вам и саботаж просто способ выражения этой неприязни, то необходимо перечитать главу Конфликтология и решать этот вопрос указанным там способом.

— Сотрудники не знают, как правильно следовать новому процессу.

— вы могли совершить ошибку, не описав нужные вещи в процессе, или ваши сотрудники невнимательно изучили сделанный материал. Так или иначе, это больше обычная ситуация нежели саботаж.

— Новый процесс имеет критические ошибки и нуждается в пересмотре

Контролируйте новый процесс первое время, как писал пластический хирург Максвелл Мальц: «Человеку нужен 21 день, чтобы привыкнуть к изменениям своего тела». Этот срок в «21 день» применяют и для других случаев, где людям необходимо привыкнуть к чему-то новому. Если это редкий процесс, то отсчитывайте 7–9 итераций этого процесса до смягчения вашего контроля.

Эволюция процесса разработки

Конструируя свой процесс, необходимо отталкиваться от основных параметров:

— Долгосрочное или краткосрочное сотрудничество у вас с заказчиком

— Насколько жестко ограничены срок и требования к продукту

Процесс разработки будет меняться со временем и на то есть определенные причины:

— Меняются люди в команде

— Меняется количество людей в команде

— Меняются требования к качеству продукта

— Появляются риски, которые сыграли

— Подходит плановая оптимизация процесса

— Появляются жалобы и предложения

Вам нужно будет достаточно часто менять и адаптировать процесс разработки к изменяющимся условиям. Есть лучшая практика для оптимизации процессов — Цикл Деминга.

Цикл Деминга (PDCA) закладывает в управление процессом постоянное улучшение качества.

Эдвард Деминг заложил два варианта для цикла управленческих действий постоянного улучшения качества: PDCA (планируй/Plan — делай/Do — проверяй/Check — корректируй/Act) и PDS А (планируй/Plan — делай/Do — изучай/Study — корректируй/Act):

— Планирование: установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.

— Выполнение: выполнение запланированных работ.

— Проверка: сбор информации и контроль результата на основе ключевых показателей эффективности (KPI). Они получаются в ходе выполнения процесса, выявления и анализа отклонений и установления причин отклонений.

— Воздействие: (управление, корректировка) принятие мер по устранению причин отклонений от запланированного результата, а также изменений в планировании и распределении ресурсов.

Цикл Деминга ни что иное как здравый смысл, примененный к любому происходящему во времени процессу, которому необходимо постоянное улучшение. Процесс непрерывного совершенствования поддерживается многими методологиями. Например, в Scrum есть встречи Sprint Retrospective, а в ITIL есть Continual Service Improvement. Так или иначе все приходят к реестру, процессу выявления улучшений и плановой работе с ними.

Есть несколько способов поиска улучшений:

— Анализ потерь на всех этапах решения задач. Такой анализ может происходить на встречах Sprint Retrospective.

— Анализировать основные метрики процессов и предпринимать действия по их постоянному улучшению. Важно обеспечить непрерывность их роста, а не большую величину роста.

Лучшие практики разработки и особенности их применения

Существует множество хороших практик разработки. Важно выбрать из них те, что подходят к конкретному случаю.

Kanban (применяем при высокой неопределенности в приоритетах/размерности задач/ бэклоге)

— Доска для наглядности не сможет вместить большого количества тикетов

— Работать с подзадачами на доске неудобно

— Приоритеты можно менять на лету

— Нет издержек на оценку задач

— Сложно попасть в сроки по плановым задачам

Scrum (применяем если можем планировать на 3+ итерации, нет фиксированного бюджета или требования могут измениться)

— не работает с совмещенными ресурсами (сотрудники, выполняющие задачи разных команд)

— работает в условиях краткосрочного планирования

— подразумевает отсутствие четкого конечного образа продукта

— кросс-функциональные команды подразумевают способность подменить одного специалиста другим (больше подходит для Fullstack разработчиков), и производство менее сложных продуктов

— подразумевает само-организованные команды, что требует найма команды с определенными soft skills

— ввиду избегания конечного образа продукта страдает область архитектурного планирования

ServiceDesk (применяем, если необходимо обеспечить единый временной норматив выполнения заявок)

— отсутствует планирование

— задачи могут быть большими, но они должны укладываться в временные рамки SLA

— приоритет выставляет поддержка, а не бизнес.

Существует еще множество различных лучших практик, подробно рассмотреть их в рамках данной книги невозможно. Для себя вы можете почитать про RUP, ITIL. RAD, Lean SD, Six Sigma, MSF. XP. PMBOK. Prince2. Но стоит четко отделять практики WoW (way of working) вашей команды, от практик корпоративного уровня SAFe, LeSS, Disciplined Agile.

Менеджер процесса разработки

Менеджер контролирует выполнение процесса, спроектированного Владельцем процесса.

«Управляешь только тем, что можешь измерить»

американский ученый и публицист Питер Друкер

Менеджер на ежедневной основе выполняет аналогичный цикл PDCA, собирая информацию о результативности, выявляя проблемы процесса и устраняя их.

Как собирать информацию?

Для каждого процесса определена измеримая цель. Более того, измерить можно не только поток работы, но и качество результатов на каждом шаге. Обычно самый простой способ — контролировать итоговый результат, быстро привлекая менеджера к этапам более глубокого контроля. Без этого каждый раз будет затрачиваться много времени на выяснение причин плохих метрик итогового результата.

Конечно, кроме всего прочего, необходимо быстро анализировать информацию — собираемые метрики должны выводится на графики.

Также оперативную информацию можно получать от исполнителей на ежедневных встречах (или других отчетных собраниях).

На основании анализа репозитория и сервиса проведения ревью можно собрать множество метрик, например:

— выгорания — коммиты, комменты в нерабочее время

— лени — мало кода, мало коммитов, мало ревью, мало задач, мало активных дней

— фокуса на задачу — простой после ревью, простой после тестирования и ожидание релиза

— качество — churn, возврат из тестирования, фиксы на проде

— bus-фактор — области изменения кода

— качество постановки задач — частота изменений описаний, churn

— технический долг — высокий complexity, низкий уровень рефакторинга legacy

Как выявлять проблемы?

Выявление проблем может быть построено на данных анализа и полученных путем изучения трендов, и пороговых значений статистических данных. На практике у вас должен быть дашборд с графиками и информацией, достаточной для понимания работы процессов и людей.

На основании выявленного отклонения необходимо исследовать природу этого события. Дедуктивным методом вы докапываетесь до исходной причины, также вы можете применить метод «5 почему». По итогу анализа вы придете к одному типу первопричины проблемы: внешние факторы, процесс, сотрудники. Копайте так глубоко, насколько это будет возможно/необходимо, ведь не докопавшись